In today's world of Service Oriented Architecture (SOA) and Enterprise Service Bus (ESB) implementations, it is possible for users to define high level constructs (like a business process) that utilize many individual services. Using these constructs, many different services can be integrated into a single cohesive unit. The heterogeneous services in this unit may be located on the same computer system, or potentially span multiple computer systems globally. In addition, whether the distribution of these constructs is on a single computer system, or multiple, may not be determined until the constructs are used at runtime.
For example, a business process typically consists of one or more steps, where a step describes an individual service or activity to be utilized in the business process. A step can be many things, such as an interface into a Customer Information Control System (CICS), an XML transformation, or a call to a Web Service. The potential capabilities and functionality of a business process step is virtually limitless. Interdependencies between steps can be defined via transitions. Transitions indicate the flow between steps in a business process.
The business process, in turn, may keep its own state. An individual step, or transitions between steps, can manipulate the business process state. The business process state is utilized to share information between steps and transitions in the business process. The business process in effect combines many services and activities into one homogenous application that is accessible via a single interface to business partners.
In SOA and ESB environments, the distributed application can be driven by many different technologies that control the flow of execution between services. These technologies include, but are not limited to, the Business Process Execution Language (BPEL), a Sonic Enterprise Service Bus Itinerary, a Sonic Orchestration Server™ Business Process, a UML Activity diagram, or ebXML.
The development of distributed applications for business activities poses new challenges to developers of such activities. In distributed environments the location of application state can vary dynamically. The state can also be located in many places simultaneously. Most current debugging methodologies in this environment require the use of primitive tracing capabilities. However, in homogeneous environments where information is located in static locations, full-featured debuggers exist. In such full-featured debugging environments, it is common place to be able to view and manipulate application state anywhere within the application. In addition, it is also common for debuggers to be able to dynamically set breakpoints, pause, and resume application while running within the debugging environment.
However, in a heterogeneous distributed environment, it is often impractical to determine the physical location of application state. Often, this information is not known to the distributed application until the distributed application is in use. In addition, the location of application state may itself be distributed dynamically over time. In other words, when executing a distributed application, it is possible for the application state to reside on different physical systems when the application is run at time ‘t’ vs. at time ‘t+1’. In such a scenario, it is extremely difficult to troubleshoot errors in the distributed application.
The issue is further complicated by the fact that the state and debugging features need to be available in individual services. The features and state available in individual services can vary greatly and need to be exposed to the debugger. For instance, a service that exposes a database may wish to expose debugging capabilities to single-step and monitor a series of SQL statements. A service that exposes a BPEL execution engine may wish to expose BPEL constructs. Errors in such an environment could reside in the shared state of the distributed application, in the state of an individual service. An additional complication occurs because in typical SOA deployments, state can reside anywhere in the world. Troubleshooting and debugging a distributed worldwide application is extremely difficult. It is difficult because the location of application state varies dynamically. It is also difficult because the type of data that requires troubleshooting and debugging varies from service to service.
What is needed, therefore, are techniques for debugging heterogeneous applications in a distributed environment.